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Remarks 

I. Background 

In an Advisory Action dated April 3, 2006, the Examiner stated: 

Applicant maintains that the prior art (Bennett) is not enabled even 
after the examiner pointed out in the previous Advisory Action that there 
is a retransmission mechanism preventing Bennett's network card from 
acknowledging lost packets. To revisit the issue, Applicant is directed to 
lines 3-5 at page 4 of the recent remarks quoting Comer's article: c The 
sender keeps a record of each packet it sends and waits for an 
acknowledgment before sending the next packet. Thus, as long as the 
ACK packet is sent out in response to valid pakcet been received (see, 
e.g., Bennett: col. 12, lines 7-1 1), the above hand-shaking type of protocol 
would not yield any lost packet been incorrectly acknowledged. 

Applicant is reminded that the above opinion had been conveyed to 
Applicant's representative, Mr. Lauer, on March 17, 2006 over a 
telephone interview, during which the examiner also offered suggestions 
regarding possible ways to overcome the prior art of record. As such, it is 
believed that this enablement issue has been clearly clarified. 

IL Applicants' Response 

Applicants' previous arguments demonstrating the deficiency of the Final 
Rejection and the lack of enablement of Bennett will not be reiterated here. The 
Examiner's statements regarding the telephone interview between the Examiner and the 
undersigned, and his rationale for claiming that Bennett is enabled, however, merit 
comment. 

The Examiner did offer a suggestion in the interview for amending the claims to a 
form that he stated would be patentable, but the undersigned respectfully declined 
making such an amendment because the Final Rejection is not supported. 

The Examiner then explained why he thought that Bennett was enabled. The 
Examiner stated that if one sent a single packet and then waited for an acknowledgment 
to arrive for that single packet or a retransmission timeout to occur for that single packet 
before sending the next single packet that Bennett could be made to work without losing 
packets. 

The undersigned responded that there is no teaching in Bennett of sending a 
single packet and then waiting for an acknowledgment to arrive for that single packet or a 
retransmission timeout to occur for that single packet before sending the next single 
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packet, and so the 102 rejection is still incorrect The undersigned also noted that such a 
modification of Bennett would not be obvious because it would require the other side of a 
TCP connection to send a single packet at a time so that the side that contained Bennett's 
device could perform without error, and because it would slow TCP communication to a 
crawl. The undersigned also notes that the Examiner's proposal contradicts Bennett's 
objective of "efficiently operating a reliable communication protocol," as well as 
eviscerating basic functions of TCP, such as the sliding window protocol. 

Applicants further respectfully submit that the Examiner's quotation from Comer 
that s The sender keeps a record of each packet it sends and waits for an acknowledgment 
before sending the next packet. is taken out of context Applicants provided the pages 
of Comer because in the Advisory Action of February 28, 2006, the Examiner did not 
seem to understand the retransmission mechanism of TCP, and that quote offered a basic 
building block for understanding retransmission for "most reliable protocols" 1 TCP, 
however, requires a sliding window protocol that provides a mechanism to communicate 
multiple packets between acknowledgments without overloading the receiver. Comer 
begins discussing this basic function of TCP later, on page 175, by stating: 

12.5 The Idea Behind Sliding Windows 

Before examining the TCP stream service, we need to explore an 
additional concept that underlies stream transmission. The concept, 
known as a sliding window, makes stream transmission efficient- . . 

A simple positive acknowledgement protocol wastes a substantial 
amount of network bandwidth because it must delay sending a new packet 
until it receives an acknowledgement far the previous packet 2 

The fact that TCP uses sliding windows and sends out multiple packets before 

receiving an acknowledgement for the first packet is well known to those of ordinary skill 

in the art and discussed, for example, on page 187 of Comer, which states: 

The TCP acknowledgement scheme is called cumulative because it 
reports how much of the stream has accumulated. Cumulative 
acknowledgements have both advantages and disadvantages. One 
advantage is that acknowledgements are both easy to generate and 
unambiguous. Another advantage is that lost acknowledgements do not 



1 Douglas E. Comer, "Internetworking with TCP/IP," Volume 1, (1991), page 173, line 
38, emphasis added A copy of pages 173-175 and 187 of Comer was provided with the 
Second Request for Reconsideration. 

2 Comer, page 175, lines 19-32, emphasis in original. 
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necessarily force retransmission. A major disadvantage is that the sender 
does not receive information about all successful transmissions, but only 
about a single position in the stream that has been received . 

On the same page, Comer states: 

Because (TCP) segments travel in IP datagrams, they can be lost or 
delivered out of order, the receiver uses the sequence number to reorder 
segments. 4 

This statement also makes clear that TCP does not wait to receive an 
acknowledgement for each packet before sending the next packet, because the packets 
could in that case never arrive out of order. Even Bennett recognizes that TCP segments 
can be received out of order, 5 although it fails to recognize that its automatic ACK 
generation would destroy the basic functions and reliability of TCP. 

Stevens also notes that TCP uses a sliding window protocol to send multiple 

packets before waiting for an acknowledgement, as is well known to those of ordinary 

skill in the art, distinguishing the mechanism proposed by the Examiner by stating: 

In Chapter 15 we saw that TFTP uses a stop-and-wait protocol. 
The sender of a data block required an acknowledgement for that block 
before the next block was sent. In this chapter we'll see that TCP uses a 
different form of flow control called a sliding window protocol. It allows 
the sender to transmit multiple packets before it stops and waits for an 
acknowledgement. This leads to faster data transfer, because the sender 
does not have to stop and wait for an acknowledgement each time a packet 
is sent. 6 

Applicants respectfully submit that TCP is so complicated that neither Bennett 
nor the Examiner understood some of its most basic functions, indicating the 
nonobviousness of the pending claims. Applicants again respectfully request the 
Examiner to reconsider the Final Rejection, because the Final Rejection has not presented 
a prima facie case of anticipation or obviousness for any of the claims, and because the 
primary reference relied upon for that rejection is nonenabled. As such, applicants 



3 Comer, page 187, lines 1 8-24, italics in original, underline added 

4 Comer, page 187, lines 6-8. 

5 Bennett, column 11, line 66 — column 12, line 2. 

6 Richard Stevens, 'TCP/IP Illustrated, Volume 1, The Protocols" (1994), page 275, lines 
3-8, emphasis in original. For the Examiner's convenience, a copy of page 275 of 
Stevens is enclosed. 
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respectfully assert that the Final Rejection should be withdraw^ and a Notice of 
Allowance provided. 

Respectfully submitted, 
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20.1 Introduction 

In Chapter 15 we saw that TFTP uses a stop-and-wait protocol. The sender of a data 
block required an acknowledgment for that block before the next block was sent In this 
chapter we'll see that TCP uses a different form of flow control called a sliding window 
protocol It allows the sender to transmit multiple packets before it stops and waits for 
an acknowledgment This leads to faster data transfer/ since the sender doesn't have to 
stop and wait for an acknowledgment each time a packet is sent. 

We also look at TCFs PUSH flag, something we've seen in many of the previous 
examples. We also look at slow start, the technique used by TCP for getting the flow of 
data established on a connection, and then we examine bulk data throughput 

20.2 Normal Data Flow 

Let's start with a one-way transfer of 8192 bytes from the host svr4 to the host bsdi. 
We run our sock program on bsdi as the server: 

bsdi % sock -i -s 7777 

The -i and -s flags tell the program to run as a ''sink" server (read from the network 
and discard the data), and the server's port number is specified as 7777. The corre- 
sponding client is then run as: 

svr4 % sock -i -nft bsdi 7777 

This causes the client to perform eight 1024-byte writes to the network- Figure 20.1 
shows the -time line for this exchange- We have left the first three segments in the out- 
put to show the MSS values for each end. 
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